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REMARKS 

Reconsideration of the Application is respectfully requested. 

I. Status of the Claims 

Claims 1, 2, 38-41, 77-80, 82, 84, and 89-91 were previously cancelled. 
Claims 3, 4, 42, 43, 81, 83, and 85-88 are canceled without prejudice or disclaimer of the 
subject matter therein. 

Claims 5, 8, 12-15, 17-24, 29-34, 37, 44, 47, 51-54, 56-63, 68-73, 76 have been amended 
and the amendments do not add new matter 
Claims 5-37, and 44-76 are pending. 

II. Telephone Interview 

Applicants thank the Examiner for all of the courtesies extended to the Applicant and his 
representative, Louis DelJuidice, on June 16, 2006. The claims and the prior art were discussed and 
no agreement was reached. As part of the interview, the Examiner discussed "reference U", A New 
Set of Rules for Information Commerce - Rights-protection technologies and personalized- 
information commerce will affect all knowledge workers, Smith et al., Communications Week , 
November 6, 1995, pg. 34 (hereinafter "Smith"). This reference was also mentioned in the Office 
Action dated April 11, 2006, on page 4, but not used to formulate a rejection. Applicants address 
the Examiner's concerns and comments regarding Smith below in the discussion of the rejections. 
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III. Rejections Under 35 U.S.C. SS 102 and 103 

Claims 3-17, 19-36, 42-56, 58-75, 81, 83, 85, 87, and 88 are rejected under 35 U.S.C. § 
102(e) as anticipated by U.S. Patent No. 5,910,987 to Ginter et al. ("Ginter"). Claims 18, 37, 57, 
76, and 86 are rejected over Ginter, in view of Liquid Audio's Liquid Audio Music-On-Demand 
System, dated October 10, 1997 ("Liquid Audio"). Applicants have cancelled claims 3, 4, 42, 43 
rendering the rejections to these claims moot. 

Applicants respectfully maintain that Ginter does not disclose all of the elements of the 
claims, but in the interest of furthering prosecution, have amended the claims. Specifically, claims 
5 and 44 have been amended to include the elements of claims 3 and 4 and 42 and 43, respectively. 
The elements of claim 44 are similar to claim 5 and claim 5 recites a validating step that includes 
"for at least one offer, referencing an electronic contract between one of a content owner and 
distributor and a retailer; determining whether the offer is consistent with the electronic contract; 
and validating the offer when the offer is consistent with the electronic contract." The Examiner 
addresses the above elements on page 8 of the Office Action dated April 11, 2006. 

Regarding the "referencing step," the Examiner cites Ginter, column 18, line 63 to column 

19, line 15 and column 45, line 58 to column 46, line 64. Ginter, column 18 etc., only discloses that 

control information can be delivered or used with content. Ginter, column 45 etc., discloses 

electronic contracts and negotiations between parties and that the rules governing content can be 

altered by changing contracts. Ginter, column 46, lines 6-15 describe how the rules can be changed. 

The evolution of control information can occur during the passing along of one or 
more VDE control information containing objects, that is control information may be 
modified at one or more points along a chain of control information handling, so long 
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as such modification is allowed. As a result, VDE managed content may have 
different control information applied at both different "locations" in a chain of 
content handling and at similar locations in differing chains of the handling of such 
content. 

The above passage is describing a "static" or "linear" system (see, infra, page 24). The information 
is passed down and as it passes a point in the value chain, the information can be updated. Ginter 
does not disclose "referencing an electronic contract" to see if the contract was updated. Ginter 
does not teach or suggest that an electronic contract is referenced to validate an offer dynamically in 
real time. Ginter is implying above that if the new rules do not reach the "location" the old rules 
will be applied since the rules must reach the "location" to update the content. The "location" 
cannot look back up the value chain for the updated information, but must wait until the information 
comes "down." 

This interpretation is supported in Smith. Smith provides an example of how, at the time of 
her article, Ginter's system (a.k.a. InterTrust) does not "phone home" or the "location" does not 
look back unless the rules are out-of date. There is no teaching or suggestion that electronic 
contracts are referenced as part of offer validation. At the time Ginter was filed, the company 
commercially embodying Ginter's disclosure, and assignee of the application, is InterTrust. 

Regarding the "determining" step, the Examiner cites Ginter, column 14, lines 14-16 and 
column 45, line 23 to column 46, line 64. Ginter, column 14 etc., only discloses that his system 
enforces commercial agreements and rights. Ginter, column 45 etc., does not disclose checking an 
offer to see if it is consistent with the terms of an electronic contract. Ginter discloses only 
enforcing rules. Ginter's rules may or may not be current or based on the current terms of an 
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electronic contract. Claims 5 and 44 require a determination that the offer is consistent with the 
terms of the contract. 

Regarding the "validating the offer" step, the Examiner cites Ginter, column 250, lines 36- 
67. Applicants submit that Ginter, column 250 etc., is only disclosing contract formation, not 
validation. As previously argued in Applicants' response dated May 10, 2005, Ginter does not 
disclose, as part of his method, looking at an existing contract, between different parties, to settle an 
offer (negotiations) between two parties in the present. Ginter may arguably suggest one or more 
ways to create an e-contract, but does not show the claimed method and system for validating a later 
offer, by a different party, against an earlier contract. Applicants' May 10 th arguments are attached 
hereto as Exhibit A, distinguishing Ginter' s negotiation system to form a contract with validating a 
new offer against a previously negotiated contract. 

Thus, Applicants submit that Ginter does not disclose all the elements of claims 5 and 44 
and respectfully request the rejection be withdrawn. Further, claims 6-37 and 45-76, depend, 
directly or indirectly from independent claims 5 and 44, respectively and are allowable based at 
least on the arguments above. 

Applicants submit that Ginter discloses a "static" or "linear" value chain management 
system and the presently claimed invention is a "dynamic" value chain management system. Ginter 
may suggest some degree of seemingly dynamic processing when rules become out of date. 
However, Ginter is firmly rooted in a static system that does not "look back" until it is absolutely 
necessary because the packaged rules have expired. Only with the benefit of hindsight (which the 
Examiner is aware is improper) can one imagine a system where Ginter' s rules expire the moment 
the rules are packaged in the VDE container with the content. This forces Ginter' s system to look 
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back for current rules the moment the container is accessed. The above concept is not taught or 
suggested in all 500+ pages of Ginter's disclosure. 

Further, Applicants submit, that the above hypothetical system is contrary to and would 
destroy the purpose of Ginter. Ginter discloses a container based system with a default that rules 
are valid throughout the value chain. Ginter teaches that the rules maybe modified at certain 
"locations" in the value chain, but never that expired rules are deliberately used. 

Addressing the Examiner's comments regarding Smith, Applicants submit (as mentioned 
supra page 20) that Smith supports the Applicants' position that InterTrust/Ginter is only a static 
management system. 

Smith, published after the initial filing of Ginter's application, discloses that "the InterTrust 
system ... won't actually 'phone home' with each new object, but will maintain [information] on 
the customer's desktop computer. The system will 'phone home' principally when [the information 
is] exhausted or . . . required." Smith, page 3. 

Smith then discusses future plans to support InterTrust applications in that the: 

Copyright Clearance Center also has an agreement with Electronic Publishing 
Resources to build a rights and permissions clearinghouse to support InterTrust 
applications. Among the services provided will be a response to InterTrust when 
applications want to ensure enclosed permissions are still valid, that prices haven't 
changed or to get new permissions. 

Smith, page 5. The above disclosure prefaces the example cited by the Examiner as support for 

certain concepts as discussed in the telephone interview. However, the paragraph above supports 

numerous points contrary to the Examiner's position. The system to perform the functions of the 

example set forth on page 5 is not enabled. Smith indicates that this system has not been built at the 

time the article was authored nor does the article teach one of ordinary skill in the art how to make 
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and use what is disclosed. Further, the developer of the system is a third party company, not 
InterTrust. Applicants submit that, due to the lack of additional information, one is uncertain if 
InterTrust conceived of this concept and if they were in possession of this embodiment at the time 
Ginter was filed. 

In addition, substantively, the combination of Ginter and Smith do not teach or suggest 
every element of the claimed invention. Smith only discloses that the pricing information is 
checked prior to consumption of the content. Smith does not teach or suggest the validating steps 
and its sub-steps of referencing an electronic contract and determining if the offer is consistent with 
the contract. There is no suggestion of the complexity of checking an electronic contract for 
updating the rules governing the content, including price. Thus, Smith does not teach or suggest the 
elements missing from Ginter. 

Applicants reviewed other sections of Ginter not addressed in the present Office Action and 
the additional text illustrates further that Ginter, as a whole, does not teach the settlement of a 
contract between two parties in the present by looking at an existing contract, between different 
parties. 

For example, Ginter discloses auditing which occurs after a transaction has taken place. One 
of ordinary skill in the art is aware that an audit cannot be performed before a transaction. Thus, 
Ginter does not teach validation of the offer between the retailer and the consumer before the 
transaction so as to allow a transaction to take place. See, at least, column 252, lines 4-1 1 

Also, Ginter arguably suggests one or more ways to create an e-contract, but does not show 
the claimed method and system for validating a later offer, by a different party, against an earlier 
contract. Claims 5 and 44 provide for a predetermined contract between a distributor and a retailer 
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previously agreed upon. An offer is presented to and exercised by the consumer. The offer is then 
validated against the previously agreed upon contract between the distributor, content owner and 
retailer before the transaction with the consumer is consummated. 

Further, the present invention centers on content and transactions concerning the content 
based on previously negotiated and agreed upon contractual terms. In contrast, Ginter centers on 
negotiations between parties to form a contract. The claimed method of validating an offer against a 
contract is in contrast to a negotiation of distribution terms among any two or all three of the parties. 

Furthermore, Ginter also does not address the problem that the earlier contract may change 
after it is first formed and before an offer is made to a consumer or the content is at a "location" that 
is not permitted to alter the rules. Ginter falls short of the claimed method, which begins where 
Ginter ends. The claimed invention allows parties outside the owner/distributor/retailer relationship 
to purchase content in accordance with the contract previously negotiated and agreed upon between 
the distributor, owner and/or retailer. The electronic contract is not accessed until the time of the 
user's request, so the most current contract is used. 

Applicants submit that Ginter discloses only a "static value chain management system." The 
term is defined in a whitepaper, The Long March to Interoperable Digital Rights Management, page 
6, written by members of InterTrust (attached hereto as Exhibit B). Ginter only discloses packaging 
the rules, either with or without the content, and sending them down the value chain. 

Exhibit B also defines a "dynamic value chain management system" and the differences 
between the two (see, Exhibit B, pages 6-7). Applicants' system and claims are a dynamic value 
chain management system, where the information is accessed as needed. The offer for the content 
is validated at the time the user wants to exercise the offer, thus when the information is needed. 
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Exhibit B cites, in three separate sections, footnote 10 to the Content Reference Forum (the "CRF") 
as the source for the dynamic features. The CRF was formed by the assignee of the present 
invention, Universal Music Group. 

Exhibit B identifies that there is a fundamental difference between a "static" and "dynamic" 
system. Exhibit B states that the dynamic system is "late binding" which implies that it is more than 
altering a setting of a static system to perform dynamic-like functions. A key "real world" 
difference noted is that static containers need "repackaging" if there are unanticipated rules or 
model changes. Wherein, "the dynamic model, rules governing the use of value chain information 
are accessed on demand" Exhibit B, page 6, emphasis added. Note that the bulk of the text 
describing the "dynamic" system is attributed to the CRF (i.e. footnote 10) and then is summed up 
further on page 6: 

Dynamic value chain management allows for modification of the value chain 
information as references to the content move through the distribution channel. The 
dynamic model allows content to be packaged without advance knowledge of 
distribution configurations. Distribution configurations can change in response to 
new contracts, law, or business models. 

In closing, Applicants submit that, in general, Ginter is a list of things one can enable using 
VDE. There is no teaching or suggestion of direct, automated linkage between negotiated contracts 
and using these contracts to automatically create or modify offers. Ginter' s disclosed system is 
VDE and distribution chain-centric. The present invention, as embodied in the claims, is contracts- 
centric. The claims recite referencing electronic contracts to automatically create or modify offers 
when an offer is needed. In contrast to VDE architecture, the present invention teaches a direct 
linkage of internal business office systems to internet commerce. 
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CONCLUSION 



In view of the above amendments, Applicants believe the pending application is in condition 
for allowance. In view of the above, each of the presently pending claims in this application is 
believed to be in immediate condition for allowance. Accordingly, the Examiner is respectfully 
requested to pass this application to issue. 

The Examiner is respectfully requested to contact the undersigned at the telephone number 
indicated below once he has reviewed the proposed amendment if the Examiner believes any issue 
can be resolved through either a Supplemental Response or an Examiner's Amendment. 
Dated: August 1 1 , 2006 Respectfully submitted, 




Registration No.: 47,522 
DARBY <S/DARBY P.C. 
P.O. Box 5257 

New York, New York 10150-5257 
(212) 527-7700 
(212) 527-7701 (Fax) 
Attorneys/Agents For Applicant 
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ARGUMENTS PRESENTED MAY 10, 2005 
REGARDING CLAIMS 5 AND 44 

There are key differences between Ginter and the present invention in claims 5 and 44. 

In summary, Ginter does not disclose, as part of his method, looking at an existing contract, 

between different parties, to settle an offer (negotiations) between two parties in the present. 

Ginter may arguably suggest one or more ways to create an e-contract, but does not show the 

claimed method and system for validating a later offer, by a different party, against an earlier 

contract. Claims 5 and 44 provide for a predetermined contract between a distributor and a 

retailer previously agreed upon. The offer is formulated, provided and exercised by the 

consumer. The offer is then validated against the previously agreed upon contract between the 

distributor and retailer. 

Specifically, the claims provide an electronic contract that was previously negotiated 

and settled between a distributor and a retailer. The contract refers to the terms under which 

the retailer can distribute information. This is the electronic contract claimed in claim 5 and 

44. The offer is provided to a consumer and the offer is related to the item of information. 

The consumer selects an offer and the offer is validated against the electronic contract. 

The validation of the offer involves "determining whether the offer is consistent with the 

electronic contract." Thus, the electronic contract is formed in advance of receiving the offer 

and the offer is thereafter validated against the electronic contract when a consumer is ready to 

make a purchase. In this way, the most up to date electronic contract is used and a consumer's 

purchases are only completed if validated. Ginter does not disclose or suggest previous 

agreements being updated and accessed dynamically for validation, so that an offer to a 

consumer (a third party) can be authorized and processed. 
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Further, the present invention centers on content and transactions concerning the 

content based on previously negotiated and agreed upon contractual terms. In contrast, Ginter 

centers on negotiations between parties to form a contract. For example, Ginter may suggest 

one or more ways to create an e-contract, but does not show the claimed method and system 

for validating a later offer, by a different party, against an earlier contract. Significantly, 

Ginter also does not address the problem that the earlier contract may change after it is first 

formed and before the offer is made to a consumer. 

Thus, the claimed validation step provides that if the terms of the offer do not match the 

electronic contract, the candidate retail offer is not validated. The electronic contract and the 

candidate retail offer do not "haggle" or negotiate to form a new contract, as taught by Ginter. 
Ginter dedicates over 9 columns to discussing the negotiation of contracts and discloses: 

Negotiation and Electronic Contracts... Electronic agreements, like traditional 
agreements, may be negotiated between their parties... Negotiation is defined in 
the dictionary as "the act of bringing together by mutual agreement." The 
preferred embodiment provides electronic negotiation processes by which one or 
more rights and associated controls can be established through electronic 
automated negotiation of terms. ... A more complex form of a negotiation is 
analogous to "haggling." In this scenario, most of the terms and conditions are 
fixed, but one or more terms (e.g., price or payment terms) are not. For these 
terms, there are options, limits, and elements that may be negotiated over. 

See, Ginter, column 241, line 55 to column 250, line 67. 

In contrast, Applicants claim that either the offer matches the terms of the electronic 
contract or it is not validated. Once validated, the content is provided to the consumer, the 
consumer pays, and the compensation is distributed to the parties per the electronic contract. 
Thus, in the claims, there are three parties involved in a transaction, the distributor, the 
retailer and the consumer. The distributor and retailer negotiate and form an electronic 
contract for the distribution of content. The consumer, who is not a party to the electronic 
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contract, is still subject to its terms because the terms of the electronic contract govern the 
validation of the offer the consumer is requesting. For example, the Specification discloses 
that: 

The retailer enters a contractual arrangement with a content owner, namely, a 
distributor, to establish the rules for the retailer to sell content from that 
distributor. Based on the contract, the distributor (via Production Systems) 
creates an electronic contract (E-Contract) which is a set of rules against which 
the retailer's unique offers can be evaluated for validity. The E-Contract is sent 
to the distributor's Reference Service. 

Specification, page 19, lines 16-20. 

The claimed method of validating an offer against an electronic contract is in contrast to 

a negotiation of distribution terms among any two or all three of the parties. Ginter differs and 

is concerned with forming an electronic contract between two parties by negotiating terms 

between them, using software (i.e. agents), until an agreement is reached or negotiations fail. 

Ginter discloses the negotiation of a contract electronically. Ginter discloses two parties to the 

contract and each party sets out their terms and preferences for the contract as a control set. 

The two control sets are in the nature of bids, and are compared electronically against each 

other to find mutually acceptable terms. Ginter defines the electronic comparison of terms as 

his "negotiation." The expression of the accepted terms becomes a new control set and is 

incorporated into an electronic contract between the parties. See, Ginter, column 241, line 55 

to column 254, line 34. 

Claim 1 of Ginter supports this interpretation: 

[a] method for negotiating electronic contracts, comprising: receiving a first 
control set from a remote site; providing a second control set; performing, 
within a protected processing environment, an electronic negotiation between 
said first control set and said second control set, including providing interaction 
between said first and second control sets; and producing a negotiated control 
set resulting from said interaction between said first and second control sets. 
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Ginter's first and second control sets are not electronic contracts. Both control sets are, at best, 



offers to sell or bids for purchase. Ginter states that: 

[o]ne control set may describe a fixed ("higher") price for using the content. 
Another control set may describe a fixed ("lower") price for using the content 
with additional control information and field specifications requiring collection 
and return the user's personal information. ... To perform the negotiation, one 
party may propose a control set containing specific fields, control information, 
and limits as specified by a PERC [Permissions Record]; the other party may 
pick and accept from the control sets proposed, reject them, or propose alternate 
control sets that might be used. The negotiation process may use the permitted, 
required, and optional designations in the PERC to determine an acceptable 
range of parameters for the final rule set. Once an agreement is reached, the 
negotiation process may create a new PERC and/or URT [User Rights Table] 
that describes the result of the negotiation. The resulting PERCs and/or URTs 
may be "signed" (e.g., using digital signatures) by all of the negotiation 
processes involved in the negotiation to prevent repudiation of the agreement at 

Ginter, ^lft\Syl a ^3, line 25 to column 244, line 5. Thus, Ginter's control sets are defined, 

exchanged, modified and negotiated until there is an acceptable agreement between the parties. 

There must be an agreement about what the control set includes (the specific fields) as well as 

the content or terms that will constitute a match. Only when all of the terms are accepted is an 

electronic contract formed, which Ginter discloses as a new control set that is "signed" by the 

parties. The definition of the term "negotiation" as defined by Ginter, "the act of bringing 

together by mutual agreement" (Ginter, column 242, lines 5-6) would lead one of ordinary 

skill in the art to realize that a contract has not yet been formed, since one does not "bring 

together" parties after a contract is agreed upon. 

Ginter falls short of the claimed method, which begins where Ginter ends. The claimed 

invention allows parties outside the distributor/retailer relationship to purchase content in 

accordance with the contract previously negotiated and agreed upon between the distributor and 

the retailer. The electronic contract is not accessed until the time of the user's request, so the 

most current contract is used. 
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Furthermore, even if Ginter suggests to one of ordinary skill in the art that three parties 
can negotiate a contract using Ginter 's method (which Applicants submit that it does not), 
Ginter still falls short of the claimed invention. Using Ginter's method, the distributor, the 
retailer and the consumer would all send control sets to negotiate a single contract, with the 
consumer's control set having input into the relationship between the distributor and the retailer. 
All the parties would negotiate contemporaneously until an agreement is reached. There would 
be no need for an offer validation step because no electronic contract would be formed prior to 
the consumer's negotiations. Alternately, if the Examiner assumes that the distributor and 
retailer use Ginter's method for one contract and the retailer and the consumer use the method 
for another, this still falls short of the presently claimed invention. Ginter's method only 
negotiates with the control sets at hand, and Ginter does not teach or suggest that control sets 
should come from a previous contract negotiated with a different set of control sets between 
different parties. 
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The Long March to Interoperable 
Digital Rights Management 

Rob H. Koenen, Senior Member, IEEE, Jack Lacy, Michael MacKay, 
and Steve Mitchell, Member, IEEE 



Abstract — This paper discusses interoperability of digital 
rights management (DRM) systems. We start by describing a 
basic reference model for DRM. The cause of interoperability is 
served by understanding and circumscribing what DRM is "in 
the whole." Then we outline and contrast three different 
approaches to achieving interoperability. One approach relies on 
flexible network services to provide functionality where it is 
needed, perhaps by bridging different systems. We describe an 
experimental service orchestration system (NEMO) that enables 
such an approach. 

Index Terms — Digital Rights Management, Trusted 
Computing, Digital Media Distribution, Standards, Web Services 

I. INTRODUCTION 

DIGITAL Rights Management (DRM) is a collection of 
technologies that enable technically enforced licensing of 
digital information. DRM makes it possible for commercial 
publishers to distribute valuable content electronically, 
without destroying the copyright holder's revenue stream. 
DRM can also be used in other settings to enable safe 
distribution of digital content including, for example, 
document management within and between corporations, 
protected email, medical patient records handling, and 
government service access. 

At a minimum, a well-designed DRM system provides: 
Governance: DRM is different from classical security and 
protection technologies [1], Conventional media distribution 
systems based on conditional access techniques protect media 
during transmission using a control model based on direct 
cryptographic key exchange. DRM systems, on the other 
hand, implement control, or governance, via the use of 
programming language methods executed in a secure 
environment. 

Secure Association of Usage Rules with Information: 

DRM systems securely associate rules with content. These 
rules determine usage of the content throughout its lifecycle. 
Rules can be attached to content, embedded within content 
(e.g., via watermarking), or rules can be delivered 
independently of content. 

Persistent Protection: DRM systems are designed to 
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protect and govern information on a persistent basis 
throughout the content's commercial lifecycle. Protection is 
frequently provided using cryptographic techniques. 
Encrypted content is protected even as it travels outside of 
protected distribution channels. 

The use of DRM in commercial end-consumer media 
distribution is controversial for several reasons. DRM allows 
content providers to create licenses that are different from, and 
more rigidly enforceable than, the de facto generally 
understood licenses that have accompanied traditional media 
(CD's, VHS tapes, and DVD's). Conversely, the nature of 
today's DRM technology makes it difficult to automate 
accurately some existing usage conventions, such as the 
United States' fair use traditions or European privacy 
expectations. 

DRM license enforcement requires security safeguards on 
home equipment to protect the interests of content vendors. 
Although it is common for basic utility vendors to install 
security systems around home metering systems (e.g., cable 
television, water, electricity and natural gas), some consumers 
are wary of DRM systems operating on their family PC, which 
is used for many personal tasks besides presenting media. 

Traditional media distribution (before the mid-1990s) has 
been tied to physical media, such as music CD's and video 
tapes. Making and distributing high-quality copies of music 
and video was difficult for the average consumer. Successful 
business models have been well established around the 
processes of manufacturing, distributing, merchandising, and 
charging consumers for individual copies of a work. Early 
electronic distribution systems have likewise been built 
around the notion of digital copies of works ("copy control 
systems"), but this paradigm is becoming less relevant as it 
becomes easier for consumers to manage content as disk files 
on their home network, in their cars, at work, and in school. 

It is easy today to find consumers who would think it 
appropriate to pay full price for a second factory pressed copy 
of a favorite music CD, but who have few misgivings about 
downloading free (unauthorized) digital compressed copies of 
music for which they (or someone in their family) already 
own a commercial CD. Consequently, consumers are 
developing their own ideas of what the right business models 
should be for commercial music licensing. Commercial 
publishers are scrambling to work through the business and 
technical hurdles to deploying business models that protect 
their interests and are acceptable to consumers, device 
manufacturers, and service providers. 
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The result is the emergence of DRM-enabled digital music 
services, such as Roxio's Napster service (originally known as 
pressplay), Apple's iTunes Music Store, Musicmatch 
Downloads, and others. Apple's music service has so far been 
the most popular with consumers, but we have not yet heard 
the last word in legal on-line music distribution [2],[3],[4]. 
BuyMusic, Musicmatch, MusicNow, Napster, and numerous 
others use Microsoft's Windows Media Audio format, which 
bundles DRM capability with an audio codec and a file 
format. Apple's iTunes uses an open standard audio codec 
(MPEG Advanced Audio Coding, or AAC) and a proprietary 
DRM system. The Microsoft and Apple formats are not 
compatible. Microsoft's format is supported on the largest 
variety of portable music players, while Apple's format is 
currently supported on only one - its own iPod. (Reportedly 
this is the current top-selling music player [3]). At the time of 
writing, no portable music player supports both formats. 

This paper focuses on the issue of DRM interoperability. 
There are several reasons why DRM interoperability is 
desirable. The content industry desperately needs to deploy 
legitimate content services that compete favorably (based on 
features, not on price) with unauthorized free services. A 
simple and seamless user experience must be part of that goal, 
and DRM interoperability is necessary to achieve it. 

Content providers and e-commerce service providers would 
like to see a healthy business climate from which they can 
multi -source essential technologies like DRM, especially 
when these technologies must adapt rapidly to evolving 
industry needs and consumer expectations. The DRM market 
is strongly influenced by network effects: a DRM technology 
becomes more valuable as it becomes more widely adopted. 
Thus there are strong forces pushing DRM technology 
providers toward interoperability, even as vendors attempt to 
differentiate their products based upon features. 

While many people have articulated a goal for media 
distribution where any content is available to anyone, anytime, 
anywhere on any useful device using viable business models, 
significant barriers exist to the goal of an interoperable and 
secure world of media related services: 

• Overlapping de facto and formal standards 

• Implementation technologies are not interoperable 

• Consumer devices cannot locate and connect to needed 
services 

• Web services standards do not bridge services spanning 
web distribution and personal area network protocols 

• Impedance mismatches between different trust and 
protection models 

• No unified notion of content governance in current 
peer-to-peer distribution models 

We outline some of the possible approaches to achieving 
interoperability, and discuss related issues. We start in the 
next section by describing a basic reference model for DRM. 
The cause of interoperability is served by understanding and 
circumscribing what DRM is "in the whole." We then outline 



and contrast three different approaches to achieving 
interoperability. One approach relies on flexible network 
services to provide functionality where it is needed. Finally, 
we describe an experimental service orchestration system 
(NEMO) that enables such an approach. 

II . Towards a DRM Basic Reference Model 

Commercial practice across a variety of DRM systems has 
matured to a point where robust technical patterns can be 
identified as a basis for establishing a DRM Basic Reference 
Model 1 . In this section, we consider the architecture of current 
DRM systems in order to identify common technical elements 
and the requirements they try to address. Proceeding from this 
analysis, we then outline a reference model that may serve as 
a basis for coordinating evolution and interoperability of next- 
generation DRM systems. Establishing a general vocabulary 
and a set of reference concepts is the first step in building a 
framework for interoperability of heterogeneous systems. 

A . Current DRM A rchitectures and Industry Practice 
Fig. 1 illustrates an abstract system architecture based on 
DRM application and service elements representative of a 
variety of contemporary commercial DRM systems. Key 
concepts in this diagram are as follows: 

• Content and associated usage rights enter the system 
through a packaging process, typically under the authority 
of the Content Licensor. 

• Packaging services produce protected content and either 
full licenses, or rules and metadata as input to a Licensing 
and Reference Service. Licenses can usually be 
personalized based on the particular parameters of the 
license-requesting party [5], 

• Consumers use a local Consuming Application to transact 
with the licensing and reference services for licenses, and 
interact with streaming or download services for 
acquisition of the protected content. Often, the licensing 
service provides the reference to the correct content and 
associated distribution source. 

• The consumer may be licensed to transfer protected 
content to another peer system (e.g. other "full-featured 
hosts"), or to a portable device with DRM capabilities. 
Portable or "tethered" devices interact with the DRM 
system by proxy via a more capable upstream system (e.g. 
the "full-featured host"). The host may for example create 
a restricted form of the original license better suited to the 
capabilities the device, or may buffer or cache certain 
usage information on behalf of the less capable device. 

Each of the elements in fig. 1 may consist of multiple 
systems in a real -world implementation. For example, 
licensing services may embody an entire distribution value 
chain consisting of retail, subscription or download services. 

Each element may be hosted by different business entities, 

1 The CEN/ISSS Digital Rights Management Final Report [16] provides an 
overview of evolving DRM technical architectures with the goal of 
"identifying the current status of DRM usage and possible means to ensure 
effective implementation of DRM in the marketplace." 
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acting in cooperation with other parties' systems based on 
contractual business relationships. Current deployment 
scenarios for DRM systems involve mutually well-known 
business partners, carefully architected technical 
responsibilities and negotiated business relationships. 
However, increased business automation and more dynamic 
business relationships create the need for flexible provisioning 
and management of DRM infrastructure. 

DRM applications and services (consumption, packaging, 
license services, provisioning services, etc.) are all built on 
elements of the trusted computing framework, which includes 
secure software distribution and execution environments, 
trusted identity management, secure policy and rule 
processing and enforcement, supporting cryptographic 
functions and key management, and tamper resistance. 
Provisioning services support adding new participants and 
services, and supplying DRM systems with supporting 
software, certificates, etc. 

The ability to programmatically configure and manage 
trusted and secure relationships between the participants and 
the underlying DRM technology is paramount [6]. All of the 
parties in the value chain must trust that distributed content or 
information and its source are authentic, is accessible only by 
intended or contracted receivers and is used by those receivers 
consistently with the contracted rights. Devices and services 
must be qualified as trustworthy and then maintained as such. 



B. Value Chains and DRM Systems 

Understanding roles in the commerce value chain and how 
these interact with DRM services is essential. 

A detailed model of roles involved in electronic copyright 
management systems was developed by the European 
Commission-funded Imprimatur project. Completed in 1998, 
the goal of Imprimatur was to "understand and analyze the 
context in which Electronic Copyright Management Systems 
are to be developed," and which "reflect [s] current business 
practices for trading and licensing multimedia documents [by 
identifying] relevant roles, their relationships and 
corresponding transactions" [5]. Roles and responsibilities 
addressed by the Imprimatur model include: 

• The Creator - the party responsible for delivering their 
creation to the Creation Provider. 

• Creators may assign exploitation rights to a Rights Holder 
(e.g. a collection or licensing agency). 

• The relationship between Creators and Rights Holders 
and associated contracts are maintained in an IPR 
Database. 

• The Media Distributor is expected to pass appropriate 
royalties to the Rights Holder according to the current 
payment details stored in the IPR Database, 

• The Purchaser (consumer) may use the creation, and if 
they generate a new composite document based on it then 
they also become a Creator. In order for the Purchaser to 
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perform functions associated with the Creator role, they 
must have obtained the required permission from the 
corresponding Rights Holder of the original creation. 
Rights Holders of original creations automatically have 
rights on composite creations - the flow of royalties is 
determined according to the IPR Database. 

Few DRM systems take all of these types of roles, 
relationships, and activities directly into account as part of 
their intrinsic design, leaving contract management, auditing 
and accounting issues to a diverse array of largely 
unintegrated back office systems. With increased end-to-end 
systems automation and sophisticated digital content 
manipulation and aggregation services, models like 
Imprimatur will likely receive increased atttention in new 
architectures. Possibly the most thorough attempt to date in a 
single DRM system was undertaken by InterTrust in its 
Commerce system [7]. 
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C. DRM Systems Functionality 

The proposed basic DRM reference model is illustrated in 
fig. 2. We now frame the functional characteristics of the five 
main domains of our proposed basic reference model. 

J) Packaging, Rules Generation and Modification 
The point of entry to the DRM-managed content and 
governance lifecycle includes technologies supporting content 
packaging, specification of rights and associated data, and 
generation and modification of digital items. 

a) Content Packaging 

Content packaging is the process of preparing content for 
DRM protection - placing content into a secure container, 
usually by encrypting it, associating the necessary identifiers 
and metadata, and logging and cataloging the content, its 
identifiers and metadata, and its cryptographic material. 
Consumers and associated consumption processes may also be 
enabled to package their own content 2 



1 The term "consumer" typically refers to retail end-users but may also 
apply to other value chain participants - regardless, consumers are participants 
of the managed value chain and may participate in a broader class of functions 
than strictly consumption and rendering. 



Content packaging can be closely associated with rules and 
license generation, or may be completely independent from it. 
Content identifiers couple the protected content with rules and 
content protection keys. Therefore, rules, packaged content, 
and content keys may be generated together or separately, at 
the same time or at different times. They may be delivered 
together, through the same channels, or separately, at different 
times, through different channels. In a production 
environment content may be packaged initially without rules. 
Alternatively, content may be packaged on-demand and 
immediately associated with rules. 

The content may contain directions as to where licenses or 
offers associated with the content can be acquired, or other 
offer metadata that can be used to automate downstream 
distribution processes. 

Content protection is typically accomplished using 
cryptographic processing, where content protection keys are 
made available to one value chain participant or consumer, 
and are not exposed in the clear to other value chain 
participants or consumers. Key management procedures can 
bind or associate a content package to any security principal, 
including individual consumers, devices, certain types of 
secure media, or content-sharing networks {e.g., a network of 
home media devices). Associating content with a consumer 
allows the protected content and license to be transported to 
other systems on which the consumer is also authorized. 

b) Rules Generation and Modification 

Any authorized member of the value chain from packager 
to consumer may create rules to be associated with a content 
package. Rules may be used to govern consumer access to 
content as well as to govern the actions of other value chain 
members on the content or information associated with the 
content. For example, usage rules may require authentication 
on access or usage, or require license updates to be obtained 
before operating on the content 3 . 

Rules may specify consequences such as generation of audit 
records based on content usage actions or attempts at usage, 
such that the audit records are securely delivered to a 
designated authority prior to execution of the action governed 
by the rule. 

Rules are often associated with the whole piece of content, 
but may also be managed at the granularity of a content sub- 
element {e.g. stream, component, etc.). Rules can also be 
associated with a class of content (e.g., all content belonging 
to a particular owner, all audio content, all low-bitrate content, 
etc.) rather than a specific content instance. 

Rules can be delivered as separate files {e.g., a license), or 
combined with the protected content (integrated with the 
content data format itself), or both. Alternatively, the rules can 
be provided as input to value chain management and licensing 
services, or applied in conjunction with processes for 
resolving references to the content. 



3 For example, expired rights might require license updates to enable access 
or usage. 
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Rules, terms and conditions, and consequences can be 
represented in a variety of different ways. For example, one 
approach is to use a standardized rights expression language 
such as the MPEG-21 Rights Expression Language (REL, [8]) 
or the Open Digital Rights Language (ODRL, [9]). 
Alternatively, rules may also be encoded in formatted text 
(such as XML or named key-value pairs), or possibly via 
compiled or interpretive code as part of an application. 

In some systems, it is possible to modify or extend rules 
after their initial creation. For example, value chain 
management and licensing services may support the ability to 
select and apply rules that have been updated to reflect up-to- 
the-minute changes in business offers, regardless of when the 
content was packaged and placed into the system. 

In the final stage of rules generation, rules are embedded 
into data structures that can be linked to the content. There are 
a variety of mechanisms available for packaging rules. For 
example, sets of rules may be organized into "offers" that 
describe the content and the associated license for presentation 
to a consumer or other value chain member. Offers may be 
delivered to a content distributor, who may choose to present 
some or all of the offers to other participants further down the 
value chain. Associated collateral information and 
promotional content can be included in a separate package for 
use in retail promotion and downstream distribution. 

2) Value Chain Management and License Services 

A common characteristic of systems that support non -trivial 
operational models (such as subscriptions, superdistribution, 
push-distribution, etc.) is the ability to produce, modify, 
assemble and aggregate rules, and negotiate conflicts 
involving rules from one or more sources.. 

Consumer licenses are sometimes the result of a 
collaboration of multiple value chain participants. Authorized 
value chain members may insert new rules into the licensing 
structures, using processes that are themselves governed. The 
rights of various services to interact with the content's 
distribution process may be encoded in rules delivered directly 
to the service or that are referenced using the same identifiers 
or references that are associated with the content. 

Value chain management services may include post- 
transaction processing {e.g., allocation of the value exchanged 
such as financial payment, usage data, etc.) per contractual 
obligations [5]. Such post-transaction processing rules can be 
included in the license associated with the content (whether 
packaged together with the license or separately), or created as 
an electronic contract covering specific offers or content and 
delivered separately. 

Historically, the terms by which value chain participants are 
allowed to interact with the content and rights to its use are 
expressed via contractual relationships between creators (or 
creation providers) and other value chain participants. We 
anticipate that contractual relationships may be automated 
using similar mechanisms (e.g. electronic contracts) as those 
used to control access to content by consumer applications. 
Contracts may be encoded using a Contract Expression 



Language [10], similar to rights expression languages used for 
encoding content usage rights. Electronic contracts are then 
delivered to participating entities and used by trusted 
applications to manage content distribution rights. The ways 
in which these terms are delivered and managed are discussed 
in greater detail in the next section. 

Frequently, rights and contractual obligations associated 
with a piece of content already exist as a result of prior 
interactions with the content (e.g. as part of prior distribution 
arrangements). Rights discovery refers to a set of functions 
provided either by technically automated or other means, such 
as conventional business processes, for referencing these 
existing rights and obligations. 

a) Value Chain Management 

Value chain management refers to those system facilities 
that track, serve and govern value chain participants. Value 
chain participants have interests in the distribution of products 
and provide decision -making, reporting, and other processing 
services affecting the digital content under their control. Just 
as rules govern the use of protected content, rules and policy 
govern the ways in which value chain participants interact 
with one another and with their associated content. 

Static value chain management refers to approaches 
where offer and consumption rules are computed at content 
packaging time. An expression of rules can be distributed with 
content packages for examination or modification by other 
participants in the value chain. 

In the static model, content packages are created for a 
particular set of distribution participants. The value chain 
management process is parameterized at packaging time with 
information about the known and identified participants, and 
the packager output conveys the necessary information in 
advance of actual participation. Once packaged, modification 
to the value chain information is governed by the associated 
rule set. The upshot of this early-binding approach is that 
unanticipated business model changes might necessitate 
content and/or rules repackaging from an original source. 

The dynamic value chain management model is late- 
binding. In the dynamic model, rules governing the use of 
value chain information are accessed on demand through 
network services, rather than being carried as they were 
encoded at packaging in an early-bound and immutable 
configuration. Rather than copying packaged files to each 
value chain participant, content may be distributed by 
reference [10]. The rights to the content are distributed based 
on these references and the references may be incorporated in 
or used by other structures, such as licenses. Reference 
Services fulfill requests for content consumption by 
consulting their current rule sets [10]. 

Dynamic value chain management allows for modification 
of the value chain information as references to the content 
move through the distribution channel. The dynamic model 
allows content to be packaged without advance knowledge of 
distribution configurations. Distribution configurations can 
change in response to new contracts, law, or business models. 
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In addition to enabling greater adaptability and responsiveness 
to changes in the business environment, dynamic value chain 
management may provide better ways to accommodate 
complex rights management issues, such as fair use rights. 

b) Licensing Processes 

License services manage and distribute content licenses. DRM 
functions associated with license services commonly include: 

• Management of data structures carrying rules {e.g. 
licenses or offers) and cryptographic information {e.g. 
content protection keys). 

• Discovery, delivery, authentication, and management of 
offers 

• License request processing, license generation, license 
association (binding) and delivery of resulting licenses to 
requesting entities (devices, services, applications or 
security principals associated with authenticated user 
identities) consistent with the requirements of the rights 
holders and governing contracts. 

• Validation of trusted status of entities requesting services 
of the system {e.g. authentication of value chain 
participants and the business relationships between them). 

• Validation of transactions from peer value chain systems 
authorizing generation and association of licenses on 
behalf of a third party. 

• Processing and validation of any rules required for 
delivery of the license, such as enforcement of geographic 
restrictions; enforcement of time restricted offers; and 
validation of credentials from the requesting party. 

• Management and enforcement of subscription data. 

• Event reporting for payment functions (or any other 
exchange of value). 

• Event reporting for usage tracking and overall system 
assurance. 

3) Consumption Services 

Consumption services are functions through which 
consumers interact with DRM content according to some 
governed action {e.g. playback rendering, editing, printing, 
annotation, aggregation, etc.). Consumption services are 
typically associated with consumer client systems, but may 
also be associated with any value chain participant that 
accesses or processes protected content, metadata, or rules. 
Systems incorporating DRM consumption services can take a 
variety of forms including: 

• Application software incorporating DRM functions for 
protected media services running on a general purpose 
OS using PC hardware. 

• Consumer electronics devices such as set-top boxes, 
multi-media appliances or game consoles, etc. 

• Wireless or personal digital appliances, including those 
capable of participating in online transactions with value 
chain management and license services, and supporting 
operational and trust management services. 

Supporting elements of distributed DRM systems, such as 



value chain management services and license services, must 
be able to establish and maintain trust with systems that host 
consumption services. Trusted consumption hosts must protect 
their operation against circumvention of local DRM 
processing functions, must enforce rules governing access to 
packaged data, and must render and otherwise use protected 
content. Systems that consume protected content typically 
employ a variety of security mechanisms and may interact 
with local or distributed security services. 

Consuming systems request and acquire protected content 
through transactions with licensing and potentially other 
services. These transactions may include information about 
the requesting system environment and user context - 
including possibly personalization data, locale, system 
capabilities, security level or evidence of current certification, 
and information about the content. Due to the potentially 
sensitive nature of some of this information, privacy 
protection is a paramount concern in these functions [11]. 

Although many systems associate protected content, using 
cryptographic techniques, to the identity of the requesting 
system {e.g. using a fingerprint based on characteristic 
attributes of the specific system, or an indelible identifier or 
key), it is also possible (and increasingly desirable) to license 
the protected content to an identity associated with an 
authenticated security principal, {e.g. the user or a role 
associated with the user). Establishing this type of association 
allows the protected content and license to be transported to 
other systems on which the user is also authorized. 

Once the license is received, the consuming system is able 
to manipulate the content according to the specified rules.. 
Rules may express, for example, limitations on the number of 
plays, time-based usage or expiration, requirements for 
enrollment in a subscription service, budget transactions with 
a local stored-value database, authorization from a content 
management system within a business or between business 
partners, etc. 

The consuming system's DRM components are responsible 
for enforcing the rules and maintaining any state associated 
with them. State information must be protected in order to 
assure integrity against circumvention for purposes such as 
unauthorized replay or redistribution. 

If the rules specify consequences, the consuming system's 
DRM components are responsible for any required local or 
distributed transactions such as usage auditing, event 
reporting 4 or metered payment. Unsuccessful event reporting 
or auditing may result in prohibitions against further access 
until such records can be successfully processed. 

Rules may also specify whether the consuming system has 
the right to copy content to another peer or portable device. In 
this case, the system's DRM components must support device 
interfaces and non-volatile state (such as copy and check-in / 
check-out counts) used to maintain compliance with the rules. 
A device or application to which the content is being 

4 Event reporting includes activities such as successful download 
notification. 



transferred must be able to enforce the applicable content 
usage rules to a required level of conformance. 

a) Consumption and Portable Devices 

In many ways, portable devices are just another class of 
consuming system. Examples of portable devices include 
personal digital music players and various types of imaging, 
games, or electronic book devices. The primary characteristic 
of a portable device is that it is usually managed by a more 
capable system, what we might call a "full -featured host," that 
is capable of direct transactions with distributed value chain 
management and license services. Portable devices typically 
rely on a secure communications channel managed by the host 
system for functions such as copying and (re-)associating 
protected content to the portable device (or a removable 
secure memory) for offline usage and rendering. 

Portable devices typically incorporate many of the 
following functions: 

• The device and/or its portable media may be registered by 
its unique identity with the host system or consumer 
electronics appliance, personal area network, license 
service, or a personalization service. 

• They are certified as compliant with applicable security 
and/or DRM specifications. This is typically represented 
by a certificate associated with the device. 

• A device may register with a host at the time of content 
transfer, by presenting credentials or a unique identity, 
allowing content to be secured to the device. 

• The device may be re-registered to a new network, 
service, etc. in which case it is unregistered from the 
previous attachments. (Content may be keyed to the 
original network and would cease to be renderable.) 

• The device may be disabled, or denied service 
("revoked"), based on its status as a trusted element of the 
comprehensive DRM system. Revocation may involve the 
invalidation of the certificates mentioned above, or 
invalidation of the software component used to transfer 
content in the host device. 

• The host system may require information about the 
portable device including its unique identity, the unique 
identity of any removable secure memory or media 
associated with it, and other functional and/or security- 
related capabilities of the device (including certificates). 

• If authorized, the host system may support format 
translation to a different protected representation that can 
be consumed by the portable device. 

• The host system may support (re-) associating rules with 
the portable device or its removable storage. 

• The host system may support (re-)packaging, re- 
encryption, and securely associating rules to a 
representation supported by the portable device. 

Host system support for a given type of portable device 
typically depends on the security level of the device and its 
DRM capabilities. Usually, rules associated with protected 



content will determine whether the host can undertake 
transactions with a portable device, and. hence the portable 
device may be required to include functionality such as: 

• A secure clock or time source 

• Dynamic device binding to a personal area network or 
home gateway 

• Secure counters for counted plays and subscriptions 

• Device or removable storage hardware unique IDs for 
secure association of rules, content encryption keys, and 
associated protected content 

4) Trust Management Services 

Trust management services are primarily responsible for 
functions supporting provisioning, certification, secure 
operation and renewability of elements in the distributed 
DRM system [12]. Trust management services are relied upon 
by features in virtually all components of the DRM system 
and typically entail functions including: 

• Support for different trust management topologies {e.g. 
peer-to-peer, web of trust, hierarchical trust models) 

• Certification of software and/or hardware 

• Registration of software and/or hardware 

• Registration of business relationships 

• Support for personalization functions provided by the 
security and protected platform services 

• Security lifecycle maintenance including renewability and 
revocation as required for maintenance of distributed trust 
and authorized participation across all system elements 
This applies to software and hardware components of all 
value chain participants and their relationships 

• User certification and credential management services, 

• Centralized audit and event logging services. 

Trust management subsystems use authorization techniques 
to regulate activities with risk potential within and between 
DRM system components. A regulated activity is approved or 
denied according to a predefined trust policy, and according to 
credentials and other evidence surrounding the activity. Trust 
policy can be as simple as a list of trusted activity partners, or 
it can be a complex decision procedure based upon activity 
parameters, such as the value being transacted, or the kind of 
security safeguards in place. 

Trust management topologies arise from the ability of 
relying parties to accept third party recommendations or 
certifications of the relied-upon party. In social contexts trust 
is rarely transitive. (A's trust of B and B's trust of C does not 
necessarily imply A's trust of C.) Nonetheless, the most useful 
automated trust negotiation systems implement some form of 
(possibly limited) transitive trust model. 

Trust management enables risk management by 
implementing trust policy. Although trust management 
systems may make use of authorization technologies to 
regulate activities with potential risk, trust management 
should not be confused with enforcement of content usage 
rules. Content usage rules implement business models, while 
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trust policy implements risk management. Different people 
with different expertise and concerns will author trust policy 
and content usage rules. Trust policy and content usage rules 
have different life cycles, and are distributed and managed 
differently. Trust policy and content usage rules are 
conditioned on different criteria, and have different 
vocabularies. While content access is an activity with risk 
potential, trust policy will apply to other activities as well. 
Despite these differences, content usage rules and trust policy 
may overlap, in vocabulary and in effect. 

5) Security and Protected Platform Services 
A trusted environment for persistent governance of rules 
and content is built on a foundation of security functions. The 
required security functions may leverage trusted hardware if it 
is available (e.g. smart cards, hardware cryptographic 
processors, or evolving standards for trusted hardware in 
general purpose PC and PDA platforms [13]). Security and 
protected platform services and technologies include: 

• Software tamper resistance, whereby host and device 
software and/or firmware is designed to provide 
protection of content buffers, persistent state, key stores; 
the program code may itself be obfuscated to reduce 
potential for reverse engineering; and techniques may be 
employed that detect and disable attacks against the 
software itself [14][15]. 

• Execution environment security, whereby host and device 
software and/or firmware can be validated with various 
integrity checks to ensure that it is legitimate and has not 
been modified. Some hosts may provide isolated 
processing compartments that protect sensitive processes 
from other processes running on the same platform. 

• Software personalization and individualization services 
that support creation or upgrade of DRM components, 
licenses and information such as certificates required for 
operation of the host or device system. 

• Authentication of the user or other elements to the 
application or local operating system, or with associated 
distributed value chain management and license services. 

Authorization to perform rules processing and actions on 
governed content typically requires that the system performing 
the functions prove the integrity of its security mechanisms to 
other services and applications with which it interacts. (This 
would be enforced by the trust policies of those services.) 
Proving integrity usually involves proving compliance with 
various published security certification criteria developed by 
the relevant stakeholders. Evidence of compliance with the 
applicable criteria is strongly associated with the client or 
device, typically through certificates that are cryptographically 
bound to the system, and integrity protected and digitally 
signed by the certifying party. These compliance certificates 
are then used both by the DRM software as part of its runtime 
validation as well as in various protocols involved in the 
acquisition of protected content, rules and licenses. 



D. DRM Interoperability and the Reference Model 
The DRM reference model described here should be useful 
for building an interoperability framework capable of 
accommodating a heterogeneous universe of DRM systems. 
The breadth of topics involved in standardizing DRM 
interoperability can be seen to be both systemic and cross- 
cutting. The functionality is cross-cutting in the sense that it 
intersects technical concerns spanning application integration, 
component software and mobile code, operating systems, 
distributed services, devices, content management and 
security services. The functionality is systemic from the 
standpoint that it must support operational and business 
concerns spanning diverse value chain relationships [5], 
establishment and management of trust relationships between 
distributed participants, and governance of valuable digital 
goods throughout their lifecycle. 

If the basic domain modeling underlying the shape of the 
DRM RM is robust (we believe it is from our work with it 
over the last year), it will support additional detail design 
work in each given domain, including the basis for mapping 
and reusing applicable standards that may already exist in 
those domains. In this capacity, we believe the DRM RM can 
provide particular value as a tool for better coordinating 
interoperability across a variety of different standardization 
projects (e.g. MPEG-21, OMA, OASIS, W3C, IETF, DVB, 
CR Forum, DOI, etc.). Indeed, we anticipate that other 
"planes" can (and may need to) be defined and mapped onto 
the current two-dimensional modeling. One category of work 
that may benefit from modeling as a separate but coordinated 
peer level plane is the design of ontologies 5 for DRM actions, 
consequences and policies, since such topics tend to defy 
confinement to a single layer and may interact with multiple 
domains. 

Fig. 3 illustrates how functionality described in section 2.3 
can be mapped onto the proposed basic reference model. 

Summarizing this section, we have outlined the structure of 
a Basic Reference Model for DRM that embodies dominant 
architectural patterns derived from observation of practice in a 
variety of current systems. DRM systems are evolving in a 
rapidly changing technical environment and thus exhibit a 
significant range of diversity in the design of interfaces and 
protocols, formats, trust and security mechanisms, protection 
mechanisms, governance semantics, and supporting 
functionality. Reference models assist in the formulation of 
common design vocabularies and concepts, which can become 
a further basis for motivating improved interoperability and 
usability. While the current model as presented is only a 
starting point, our experience is that it is an effective tool for 
factoring and organizing technical issues in DRM 
architectures. 



5 The MPEG-21 Rights Data Dictionary (RDD - ISO21000 part 1) is an 
example of one such standardized ontology 
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• Rights Specification 
• Rules Packaging 

- Contents Packaging 
- Content Protection 

• Key Management 



- Content Distribution 
• Secure Online License Distribution 
• Rules and Governance Policies Distribution 
• Value Chain Management 




Device Registration 

• Acquire Content and Rights 

• License Processing 

• Copying or Moving Content 



Establishment of Value Chain 
Trust Relationships 



Protection of Cryptographic 
Secrets 

Protection of 
DRM Content Processing 

Protection of Stateful 
Information 



- Secure Channels 



-Trusted Hardware and 
Software (Personalization) 



- Tamper Resistance for 
DRM Processing Functions 



Fig. 2 - Example Functionality Mapping Onto DRM Basic Reference Model 



III. Interoperability and Directions in Next 
Generation DRM Systems 

This section focuses on interoperability in DRM systems, 
and especially the role of interoperability standards. We ask 
the reader to keep the DRM reference model in mind, as 
technical analysis of interoperability strategies and the 
discontinuities underlying systems' non-interoperability also 
tend to highlight the most important interfaces, services and 
subsystems, and formats and processing points to be 
addressed in ongoing development of the model. 

A. Approaches to Interoperability in DRM Systems 
End-to-end format, services, and device interoperability are 
desirable goals, both for end-users and others involved in the 
digital content lifecycle. Normative specifications for end-to- 
end interoperability are the province of various standards 
bodies - many such efforts are in progress at this time [1]. 
Due to the variety of standards used for different modes of 
distribution, and the diversity of proprietary technologies in 
the absence of any authoritative standard, full interoperability 
is unlikely any time soon through standards-setting activities 
alone. Even where degrees of end-to-end interoperability are 
possible within a particular industry segment, consumer 
demand and new business opportunities frequently introduce a 
requirement for interaction with systems built on different 
agreements and standards. 

Full interoperability can be addressed in several different 
ways, which we explore in the following sections. 

J) Full Format Interoperability 
Full format interoperability expects that the interchange 
representation of the digital content can be consistently 
processed based on agreement between all participants in the 
value chain. The audio CD and the DVD are good examples. 
All participants (creators, distributors, manufacturers, etc.) use 



the same data representation, encoding, protection scheme, 
trust management, key management, etc. Usually there is 
some renewability infrastructure in place to cope with security 
breaches, but in severe cases, the associated standard may 
need to be updated. Full format interoperability usually entails 
robustness criteria and a certification regime to establish 
trustworthiness and security of conformant implementations. 

Pros: Makes it very easy to produce, distribute, and use 
digital content. Also makes it easy for diverse participants to 
economically build mass market applications and devices. 
Promotes efficiency by discouraging redundancy. 

Cons: The approach is rigid. Developing industry standards 
is a long process, to be undertaken when industry 
requirements are understood. Adoption requires a critical mass 
in industry which can take years to establish.. The 
mechanisms specified in a standard may not be the optimal 
choice in any particular market niche. Also, the approach can 
be vulnerable: an attack on one system can compromise all 
simultaneously, perhaps by simply distributing "cracks" on 
the Internet. Some parts of most DRM security systems (e.g., 
obfuscation, aspects of tamper resistance) rely upon "security 
by obscurity" for effectiveness, which is vulnerable to a lack 
of diversity. Most standardization processes support neither 
the required certification processes nor the short response 
cycles in case of breaches. Industry segments will need to 
provide renewability services and certification infrastructures. 

2) Connected Interoperability 

Connected interoperability builds on the expectation that 
consumers will have online access, and relies upon online 
services, some of them possibly transformative or capable of 
complex negotiation, to solve interoperability problems in a 
transparent way. While different parties may do things in 
different ways, translations or bridges exist between the ways 
different parties perform DRM functions, and that mutually 
trusted parties can perform these translations transparently, as 
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long as devices are connected at least some of the time. 

Pros: Makes it possible for different parties to choose their 
own solutions, and to ensure that security can be renewed, 
while still providing a certain type of interoperability to end- 
users. Shifts the burden of responsibility for interoperability 
from coalitions of manufacturers to on-line service providers. 

Cons: Lacks the straightforward simplicity of full format 
interoperability. Semantic mismatch between different 
systems must be overcome so that cross-boundary content 
flows appear natural. Rights may be restricted to a least 
common denominator when crossing boundaries, for technical 
and business reasons. Some classes of products will not meet 
the requirement for online connection. This still requires a 
direct trust relationship between the coordinating parties to 
govern the domains between which transforms should take 
place, or a trusted third party that can negotiate the transform. 

3) Configuration-driven Interoperability 

Configuration-driven interoperability assumes that system 
components ("tools", possibly from different vendors) can be 
downloaded and/or configured in real-time at e.g. the 
consumer's device or software application. This allows 
consumer systems to effectively "acquire" functionality on 
demand in order to accommodate new formats, protocols, and 
so on. Ideally the consumer need not even be aware that the 
dynamic configuration is occurring. This is the main concept 
underlying the MPEG-4 IPMP-X (extensions) approach [17]. 
It emulates the behavior of many software music players that 
can host downloadable compression codecs. 

Pros: Presumes a very late-binding, on-demand model that 
pushes capability to the consumer's system. Depending on 
how the interoperability tools are delivered to the consumer, 
online access may not be required, or at least may be 
minimized once the configuration is installed. 

Cons: Expects that the target platform on which the 
configurable and downloadable tools execute is capable of 
hosting and running an arbitrary number of different 
configurations. This may be troublesome for small consumer 
electronic devices. Multiple formats can be processed with 
multiple hosted tools, but the establishment of trust between 
these components and the host environment still remains - a 
problem that is not yet addressed by MPEG's IPMP work. 

B. Which Approach to Take? 

DRM systems interoperability is a challenging problem and 
there are no easy, universal solutions. While the approaches 
outlined above have individual merits, they are most likely to 
find utility in combination. In order to understand how to 
weigh the trade-offs involved in applying them, we outline a 
set of supporting principles. 

1) Apply Full Format Interoperability Wherever Possible 
Standardization efforts should apply full format 
interoperability as far as they can - things should not be done 
differently just because it is difficult to establish a common 
agreement. Standards should only accommodate alternative 



options when there is a valid technical or business reason to 
do so. Otherwise, the resulting specification may take on so 
much overhead that it becomes too costly or complex for any 
set of parties to achieve an interoperable result. The success of 
the MP3 and MPEG-2 standards is instructive. 

2) Do Not Hide Non-Interoperability, but Minimize It 
When full interoperability is not possible, this should not be 

hidden this under layers of abstraction or indirection. They do 
not bring the solution closer, but will make implementations 
more costly and less feasible. In particular, the goal should be 
to put all the non-standard elements in a single, monolithic 
block, and to make these monolithic blocks as small as 
possible, leaving very little to be defined elsewhere. Of all the 
elements left in such a block, DRM interoperability standards 
should carefully consider whether they can be agreed upon 
without compromising security - arguably the only valid 
reason not to agree on a common way to solve a problem. As 
mentioned earlier, the security of some parts of most DRM 
systems depends upon diversity and obscurity. 

3) Employ Transform Services to Bridge Non- 
Interoperability 

Consumer demand and new business opportunities 
frequently introduce the need for interaction with other 
systems built on different agreements and standards. 
Following from the previous principle, non-interoperable 
elements should be defined so that transform tasks {e.g. 
formatting, encoding or license transformations) between 
different systems are as straightforward as possible. This will 
further interoperability in a number of ways: 

• It will reduce the technical issues, thus facilitating design 
and development of transform services 

• It will facilitate the provision of content in different 
systems simultaneously 

• It will facilitate creation of consumer solutions that 
support multiple systems. 

C Technologies for Full Format Interoperability 
We examine a few pieces of the DRM reference model and 
discuss specific issues around standardization. 

1) Transport Formats, Compression, and Bulk 
Encryption 

Music and especially video presentations are large. For the 
foreseeable future, it will continue to require a noticeable 
amount of network bandwidth, storage space, and computing 
power to move, manipulate, or transform media content. 
Perhaps the greatest advantage from full format 
interoperability can be had from standardizing processes that 
directly manipulate content bits:. This includes transport (file) 
formats, compression (codec) formats, and bulk encryption of 
media bits, for file download, Internet streaming, and 
broadband broadcast. Currently, these technologies are often 
bundled together in proprietary combinations. 
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2) Content Key Distribution 

The security Achilles' heel of most cryptographic systems 
is key management [18]. While encrypted content may be 
secured with military-grade algorithms, the content is no more 
secure than are the content encryption keys. What's worse, 
content encryption keys are small and can more easily be 
distributed across the Internet, singly or in bulk, than content 
itself. While DRM-enabled clients are responsible for 
verifying usage rules associated with protected content, any 
security analysis has to consider the possibility that clients 
will be compromised - which is where the art of designing 
key distribution schemes comes into play. The goal is to limit 
the potential damage resulting from a security attack by 
limiting the value exposed to individual clients. One simple 
strategy is to encrypt a commercial movie with many different 
sets of content keys, so that if an attacker obtains keys to one 
copy of the movie, he cannot reliably redistribute keys to all 
circulating copies of the same movie. In the extreme case, 
content keys can be unique for each copy of a digital work. 

Standardizing key distribution is problematic. Security 
demands that key distribution schemes be obscure (so that 
observers cannot reverse engineer key handling paths), 
diverse (so that successful attacks on one client do not 
compromise the entire infrastructure), and renewable (so that 
compromised systems can recover from attacks). Even the 
means of association between content keys and content files 
may be considered sensitive or renewable information. 

In addition to keeping content keys confidential, DRM 
clients must also worry about keeping identity credentials 
(e.g., private keys) secret. An attacker can obtain content keys 
if it knows how legitimate clients authenticate themselves, or 
prove they are legitimate. It benefits attackers if these 
mechanisms are well known, widespread, and stable. 

One notable key distribution scheme that has been proposed 
for multimedia content protection in home networks is IBM's 
xCP protocol [19]. xCP uses a symmetric key distribution 
scheme ("broadcast encryption" [20]) originally developed for 
multicast applications. Each content key is locked inside a 
large Media Key Block, which is made available to devices on 
the network. Each device protects a set of secrets, which it can 
use to unlock Media Key Blocks and obtain content keys. If a 
device leaves a network, perhaps by being "revoked", then the 
revoked device's keys will no longer unlock newly generated 
Media Key Blocks. Standardized multicast key distribution 
schemes would be beneficial for distribution of content keys 
on fixed media, such as CD's or DVD's, since for this 
distribution mechanism there is no possibility of negotiation 
between the consuming client and the key provider. 

3) Provisioning and Security Services 

Every consuming device or application that provides or 
consumes cryptographic services must be provisioned or 
initialized with its individual set of secrets, trust anchors, and 
credentials. Many consuming devices will need to use other 
security services, in order to receive security upgrades, to 
refresh keys and certificates, to contact secure time servers, 



and to report suspected security attacks. 

There are two related difficulties with standardizing such 
security services. The first difficulty relates to client privacy 
issues. The second difficulty stems from the requirement for 
clients to authenticate and prove their integrity to remote 
services. Platform integrity is further related to tamper 
resistance, which in practice is based on proprietary 
techniques. New computing platform security and integrity 
standards [13] may help. 

4) Trust Management 

No multi- vendor multi -component system can operate 
without a means for establishing and verifying trust among the 
components and the entities served by the components. The 
best known standardized trust management system is the 
hierarchical PKI model first put forward in the X.509 standard 
[21]. The basic X.509 system uses hierarchical certifications 
and anchors trust in a root certification authority. Public-key 
cryptography provides the technical means of verifying the 
integrity of certificates. 

Trust management decisions must be made on client 
devices, and may be required more often than content access 
control decisions. Hence, the complexity of trust management 
operations is of concern. Public key cryptography operations, 
especially producing digital signatures, are computationally 
expensive. Trust models for backend services can be more 
elaborate, although performance is still an issue there. 

Hierarchical trust models with top-level "roots of trust" are 
convenient for closed-system deployments, but are 
problematic for dynamic, global deployments. First, a root of 
trust takes at least delegated responsibility as a certification 
authority for his descendent entities, but it cannot be expected 
that a single authority will be competent or willing to take 
such responsibility universally for all credential-issuing 
entities. Some entities should be trusted independently of 
others. This makes sense also when trust relationships are 
dynamic. Second, a system that relies on a root of trust 
becomes a slave to its own success. The number of parties 
relying on the root of trust makes it very difficult for the root 
to modify its policies and procedures. This seriously inhibits 
the system from growing and innovating. In the most general 
case, each stakeholder in a transaction or activity should act as 
his own ultimate root of trust. He may delegate trust to well- 
known authorities, but the system should support independent 
selection of trust authorities and trust anchors [12]. 

While trust itself can not be standardized, standardization of 
trust management for media DRM should be possible, but the 
first steps must be identification of a dictionary or vocabulary. 
It must be decided who needs to be trusted, to perform what 
activity, under what conditions. This is probably more 
important to standardize than the exact language for 
computing decisions based upon trust policy and evidence. 

5) Usage Rule Expression 

Producers and consumers of content need to share a 
common license language for expressing the usage rules 
attached to content. As with trust management, the 
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standardization of vocabulary and identifiers is probably more 
crucial than the choice of a specific language. Every DRM 
system in deployment has a means of expressing usage rules. 
Probably the simplest is the 4C Entity's Copy Control 
Information (CCI [22],[23],[24]), used in the 5C 
DTCP/Firewire access control standard [25] and the 
DVD/CSS access control system [26]. The Copy Control 
Information for a digital work consists of two bits, indicating 
whether the work can be copied one generation, copied never, 
no more, or freely. A copy of "copy once" content is per force 
"copy no more" content. "Copy never" content differs from 
"copy no more" content, in that "copy never" content should 
only appear in its original form, never in a copied form. 

At the other end of the spectrum is the MPEG-21 REL [8], 
which defines a vocabulary of media-related concepts, and 
inherits by extension a larger vocabulary through the MPEG- 
21 Rights Data Dictionary. REL is purely declarative, 
resembling a logic programming language in that it supports 
"for all" quantified variables, assertions of fact, and recursive 
computation. REL supports delegation and chaining of 
licenses (through the "issue" right), although the way REL 
chaining interacts with the time line differs from other chained 
assertion languages like SPKI [27] or X.509. These features 
give REL much of its expressive power and also much of its 
complexity. REL's syntax is expressed in XML, which makes 
typical licenses much larger than the two bits required for 4C 
Copy Control Information. 

There are many other rights expression formats in use. Paul 
Kocher advocates a system that uses a virtual machine 
bytecode to express licensing, security, and trust conditions, 
written against a standard API of host-supplied services [28]. 
Similar concepts were also explored by the OPIMA standards 
project [29]. Kocher argues that the delivery of bytecode 
means that security implementations can be renewed with 
each new piece of content, but other techniques must still be 
used to renew the implementation of the virtual machine, and 
to prevent reverse engineering of the virtual machine. 

IV. NEMO -an Approach to Connected 
Interoperability 

Some interoperability problems, especially those involving 
heterogeneous DRM systems, can be addressed by employing 
on-line negotiations. This is becoming more feasible in 
today's climate of ubiquitous always-on or frequently-on 
network access. NEMO (Networked Environment for Media 
Orchestration [30]) is an experimental framework being 
developed at InterTrust for the discovery, access, composition, 
and orchestration of media-related on-line services. 

A. An Introduction to NEMO 

NEMO allows service access across multiple network tiers 
- wide area networks, local area networks, home networks 
(e.g., over UPnP [31] or Rendezvous [32]), and personal area 
networks (e.g., over Bluetooth [33]). NEMO supports multiple 
local and remote interface bindings (e.g. WS-I [34], Java 
RMI, DCOM, C, .Net, etc.) allowing integration with 



applications. NEMO allows the use of multiple discovery 
protocols (UDDI [35], JINI [36], UPnP, Rendezvous) for 
finding NEMO services. NEMO supports (and encourages) 
the active composition and orchestration of services to 
perform complex tasks on-line. The idea is that orchestration 
and composition will allow service configurations to adapt 
and optimize to changing needs, such as when a personal area 
network moves into range of new home network devices. 

An instance of the NEMO framework consists of a logically 
connected set of nodes that interact in a peer-to-peer fashion. 
NEMO nodes interact by making service invocation requests 
and receiving responses. The format and pay load of the 
request and response messages is defined in XML. The 
NEMO framework supports the construction of diverse 
communication patterns ranging from direct interaction with a 
single service provider to a complex aggregation of a 
choreographed set of services from multiple service providers. 
The framework supports the basic mechanisms for using 
existing service choreography standards and allows service 
providers to use their own conventions. 

A service interface may have one or more service bindings. 
A NEMO node may invoke the interface of another node as 
long as that node's interface binding is described and the 
requesting node can support the conventions and protocols 
associated with the binding. E.g., if a node supports a web 
service interface, a requesting node may be required to 
support SOAP, HTTP, WS-Security, etc. Any service 
interface may be controlled in a standardized fashion directly 
providing aspects of rights management. All interactions 
between NEMO nodes can be viewed as governed operations. 

The Workflow Collator (WFC) helps fulfill most non-trivial 
NEMO service requests by coordinating the flow of events of 
a request, managing any associated data including transient 
and intermediate results, and enforcing the rules associated 
with fulfillment. Other examples of this type of functionality 
can be seen in the form of transaction coordinators ranging 
from simple transaction monitors in relational databases to 
more generalized monitors as seen in Microsoft MTS/COM+. 
The Workflow Collator is a programmable mechanism 
through which NEMO nodes orchestrate the processing and 
fulfillment of service invocations. 

We use the concept of profiles as an organizing principle in 
NEMO. A profile is the set of thematically related data types 
and interfaces defined in WSDL for the NEMO framework. 
Currently we have two profile categories: "Core", which 
includes the foundational set of data types and service 
messages necessary to support fundamental NEMO 
framework interaction patterns and functionality, and "DRM" 
which describes the Digital Rights Management services that 
can be realized with NEMO. 

Some services defined in the NEMO Core profile include: 

• Authorization - services related to authorization of a 
participant (such as node) to use a resource (service). 

• Peer Discovery - services related to the discovery of 
NEMO nodes. 

• Notification - services related to the delivery of targeted 
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messages to a given set of nodes. 

• Service Discovery - services related to the discovery of 
services provided by some set of service providing nodes. 

Some basic services defined in the NEMO DRM profile 
include: 

• Provisioning - services for obtaining the necessary 
credentials, policy, and other objects necessary for a 
consumer electronics device, software application, etc to 
participate within a specific context that uses DRM. 

• Licensing - services for obtaining DRM licenses. 

• Membership - services for obtaining objects that establish 
membership within some designated domain. 

We have not yet tried to define a formal categorization of 
NEMO peer roles based on service type groupings. However, 
based on existing functionality and observed patterns we have 
defined a preliminary set of roles that may be formalized over 
time. These include: 

Client - this is the simplest role where no services are 
exposed and the peer simply uses services of other peers. 

Authorizer - this role denotes a peer acting as a Policy 
Decision Point (PDP) determining if the requesting principal 
has access to a specified resource with a given set of pre- 
conditions and post-conditions (consequences, obligations) 
[37]. 

Gateway - in certain situations a peer may not be able to 
directly discover or interact with other service providers, for 
reasons including: transport protocol incompatibility, inability 
to negotiate a trusted context, or lack of the processing 
capability to create and process the necessary messages 
associated with a given service. The Gateway role denotes a 
peer acting as a bridge to another peer in order to allow 
interaction with a service provider. From the perspective of 
identity and establishing an authorized and trusted context for 
operation, the requesting peer may actually delegate to the 
Gateway peer its identity and allow that peer to negotiate and 
make decisions on its behalf. Alternatively, the Gateway peer 
may act as a simple relay point forwarding or routing requests 
and responses. 

Orchestrator - in situations where interaction with a set of 
service providers involves some type of non -trivial 
coordination of services possibly including transactions, 
distributed state management, etc, it may be beyond a peer's 
capability to participate in such a scenario. The Orchestrator 
role is a specialization of the Gateway role. A peer requests an 
Orchestrator peer to act on its behalf, intervening with one or 
more services. The orchestrating peer may use certain 
additional NEMO components such as an appropriately 
configured Workflow Collator in order to satisfy the 
orchestration requirements. 

B. Consumer Media Applications 

Since our ultimate goal is to enable the oft-repeated "instant 
gratification of request for any media, in any format, from any 
source, to any place, at anytime, on any device complying 
with any agreeable set of usage rules," we developed an 



informal model that helps us demonstrate how we use NEMO 
to achieve this goal. This model helped us in the separation of 
concerns process in system architecture discovery. The model 
is roughly aligned with the Basic DRM Reference Model 
outlined previously, but is more specialized for our networked 
application. The model spans heterogeneous network tiers, 
and illustrates some realistic interoperability problems. We 
explain the highest level of the model, and then we show how 
NEMO allows low level services from different tiers in the 
model to be assembled into richer end-to-end media services 

1) A Media Distribution Model 
In this model there are four tiers of service components: 

1) Content Authoring, Assembly, and Packaging services, 

2) Web-based Content Aggregation and Distribution 
services, 

3) Home Gateway services, and 

4) Consumer Electronics (CE) devices. 

Each of these four tiers clearly has significantly different 
requirements for security, rights management, service 
discovery, service orchestration, user interface complexity, 
and other service attributes. The first two tiers fit very roughly 
into the models that we see for "traditional" web services, 
while the last two tiers fit more into what we might call a 
personal logical network model, with certain services of the 
home gateway being at the nexus between the two types of 
models. However, services of CE devices could occasionally 
appear in any of the tiers. Thus, we have the dilemma where 
we want to specialize parts of the framework for efficiency of 
implementation, while being general enough to encompass an 
end-to-end solution. 

For relatively static and centralized web services, a UDDI 
directory and discovery approach may work well, but for a 
more dynamic transient merging of personal networks, 
discovery models such as found in UPnP and Rendezvous are 
more appropriate. Thus, we need to be able to include multiple 
discovery standards in our framework. 

When rights management is used for media distribution 
through wholesale, aggregator, and retail distribution subtiers, 
there can be many different types of complex rights and 
obligations that need to be expressed and tracked. This 
requires a highly expressive and complex rights language, 
sophisticated content governance and clearing services, and a 
global trust model. However, rights management and content 
governance for the home gateway and CE device tier 
generally requires a different trust model and needs to 
emphasize fair use rights that are straightforward from the 
consumer's point of view. Peer devices in a personal logical 
network want to interact using the simple trust model of that 
network, and they need to interact with peers across a wide 
area network using a global trust model perhaps through 
proxy gateway services. 

At the consumer end, complexity arises from automated 
management of content availability across devices, some of 
which are mobile and intermittently intersect multiple 
networks. Thus, our approach to rights management, while 
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enabling end-to-end distribution, is heterogeneous, supporting 
a variety of rights management services, including services 
that interpret distribution rights expressions and translate 
them, in context, to individual consumer fair use rights in a 
transaction that is orchestrated with a sales transaction or 
another event where a subscription right is exercised. 

2) NEMO Solutions 

We are currently using NEMO to link various consumer 
devices to a number of different services in the multi -tiered 
environment described above. We have successfully 
demonstrated interoperability in one interconnected system 
using cell phones, game platforms, PDAs, PCs, web-based 
content services, discovery services, notification services, and 
update services. We support multiple media formats {e.g. 
MP4, Windows Media, and others), multiple discovery 
protocols (over Bluetooth and through registries such as 
UDDI, LDAP, and Microsoft Active Directory), and IP-based 
notification and wireless SMS notification on the same device. 
We use the orchestration feature to help the consumer 
overcome interoperability barriers. When there is a query for 
content, orchestration coordinates the required services in 
order to fulfill the request, including, discovery, search, 
matching, update, rights exchange, and notification services. 

We are attempting to converge on a state where a consumer 
can use most any device, make a wish for content, and be 
instantly fulfilled with the content and the rights and rendering 
capabilities (within obvious limits of the hardware) to both 
use and share the content. The orchestration capability allows 
the consumer to view all home and internet-based content 
caches from any device at any point in a dynamic multi -tiered 
network. We are extending this capability to more advanced 
services that promote sharing of streams and play lists, 
making impromptu broadcasts and narrowcasts easy to 
discover and connect to, using many different devices, while 
ensuring rights are respected. 

3) Connected Interoperability 

Beyond the consumer-centric side, we are looking at ways 
to provide an end-to-end interoperable media distribution 
system that does not rely on a single set of standards for media 
format, rights management, and fulfillment protocols. Value 
chains that include content originators, distributors, retailers, 
service providers, device manufacturers, and consumers, 
exhibit a number of localized needs in each segment. This is 
especially true in the case of rights management, where 
content originators need to express rights of use that may 
apply differently in various contexts to different downstream 
value chain elements. A consumer gateway has a much more 
narrow set of concerns, and an end user device has a yet 
simpler set of concerns, namely just playing the content. 

With a sufficiently automated system of dynamically self- 
configuring distribution services, content originators can 
produce and package content, express rights, and confidently 
rely on value added by other service providers to instantly 
provide the content to all interested consumers, no matter 



where they are or what kind of device they are using. We use 
NEMO to fulfill this goal and provide means for multiple 
service providers to innovate and introduce new services that 
benefit both consumers and service providers without having 
to wait for or depend on a monolithic set of standards. 

This approach allows digital rights management to be 
decomposed into components with a more natural separation 
of concerns that focus on policy management of service 
interfaces rather than on copy protection. This has the 
potential to change the tension between consumers and 
content providers in the digital content domain as the NEMO 
enriched infrastructure provides consumers with better 
information, more useful services and instant gratification. 
Policy management can limit the extent to which pirates can 
leverage those legitimate services. NEMO allows the network 
effect to encourage the evolution of a very rich set of 
legitimate services providing better value than pirates can 
pro vide. + 

V. Conclusions 

We have argued that interoperability is very important to 
the success of DRM. We have explained the concepts behind 
digital rights management, and provided a basic reference 
model that embodies patterns representative of current 
architectures, and which can serve as a basis for coordination 
of interoperability solutions in next generation DRM systems. 
We have enumerated the pros and cons of three separate 
approaches to DRM interoperability, and discussed issues 
related to standardization of specific DRM-related 
technologies. We have presented an experimental system that 
supports interoperability of heterogeneous DRM systems via 
on-line services and service orchestration. 

Looking forward, DRM systems must continue to evolve in 
order to achieve interoperable, secure, media-related 
ecommerce in a world of heterogeneous consumer devices, 
media formats, communication protocols and security 
mechanisms. Today significant barriers exist to the goal of an 
interoperable and secure world of media related services. 
Standardization can solve some interoperability problems, but 
standards are not always universally applied. Where 
heterogeneous systems exist, dynamic late-bound network 
services can supply required functionality, including bridging 
services. But, in the end, DRM is about protection. A DRM 
system will not interoperate if it does not want to. 
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